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(57) Abstract: Transmission of messages composed on one or more input devices to a single or multiple recipients by means of one 
or plural communication modes is facilitated. Such communication modes may include conventional or wireless telephone, facsimile 
transmission, pager, e-mail, postal mail or courier. An application program interface (API) mediates between remote applications 
requesting messaging functions and a message server that actually implements these fonctions. The API is capable of processing 
high -volume requests for message routing, status information, and various other functions on an automated basis, enabling businesses 
to make routine use of these functions. 
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APPLICATION PROGRAM INTERFACE FOR 
MESSAGE-ROUTING AND MANAGEMENT SYSTEM 

FIELD OF THE INVENTION 

The present invention relates to communication services, and in particular to 
delivery of messages to selected recipients through one or more specified communica- 
tion modes. 

BACKGROUND OF THE INVENTION 

Thanks to improvements in technology and widespread consumer interest, once- 
exotic forms of communication have become commonplace, and today the average 
consumer has access to a broad array of communications services. The Internet and 
wireless telephony, once the preserve of an elite few, now routinely supplement tradi- 
tional telephone services and are frequently supplied by the same carriers. Even inex- 
pensive home computers now include facsimile capability. Businesses employing mo- 
bile employees can furnish them with economical pagers that incorporate advanced 
features, such as text transmission and Internet access. 

The sheer proliferation of communication options, while greatly improving ac- 
cess and convenience, has engendered problems as well. The existence of a communi- 
cation channel does not ensure that the recipient of a message will be "listenmg" to that 
particular channel at a given tune, yet the sender of a message has no way to know this. 
Indeed, more channels of communication traflBc mean more demands on the attentions 
of potential recipients, who, feeling besieged by the assault of e-mail, voice mail, 
pages, etc., may simply inactivate some communication devices at different times. 
Message senders, therefore, are faced with the choice of risking non-delivery of their 
messages, or painstakingly re-transmitting a message on every possible mode of com- 
munication modality. 
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It may also be difficult to transmit the same message to multiple recipients. 
While a single e-mail message, sent once, can reach an unlimited number of destina- 
tions, phone messages must be repeated for each call. Moreover, different recipients 
may have access to different types of communication channels; perhaps some recipients 
can be reached efficiently only by e-mail, others by fax, and still others by page. 

The integration of communication input devices also raises the prospect of mes- 
sages having multiple forms of content. Today, a single message may include input 
from a variety of sources (e.g., voice and text); transmitting such a message by tradi- 
tional means may be quite cumbersome, involving multiple separate transmissions that 
must be coordinated or difficult "packaging" of the different inputs into a single mes- 
sage. 

U.S. Serial No. 09/496,170, filed on February 1, 2000 and entitled Multi-Mode 
Message Routing and Management (the entire disclosure of which is hereby incorpo- 
rated by reference) addresses these difficulties and discloses, inter alia, a facility for 
transmission of messages composed on one or more input devices to a single or multi- 
ple recipients by means of one or plural communication modalities. Such communica- 
tion modalities may include, for example, conventional or wireless telephone, facsimile 
transmission, pager, e-mail, postal mail or courier. Thus, a message may be directed to 
a single recipient via multiple modalities, such as e-mail and fax, in order to ensure the 
earliest possible receipt of the message; or may be directed to multiple recipients by a 
single modality or by different modalities (e.g., some recipients receive the message by 
e-mail, others by fax, others by phone). The facility may be configured to respond to 
defined "escalation" rules that specify conditions under which different delivery mo- 
dalities may be sequentially employed. For example, the mles may specify that if there 
is no response to an e-mailed question within an hour, the recipient is to be telephoned. 
Moreover, in addition to alternative transmission modalities, the escalation rules may 
specify alternative recipients (as well as alternative modalities for those recipients). 
The escalation rules may also specify default contact methods, which may apply to spe- 
cific individuals or to lists of recipients. 

The invention disclosed in the ' 170 application may include functionality for 
determining whether a message has been received (e.g., telephone and e-mail polling). 
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as well as automatic sender notification upon confirmation of receipt. Moreover, in 
addition to monitoring messages in order to confirm their receipt, the invention may 
facilitate recipients' responses. In this way, the invention can orchestrate multi- 
question surveys utilizing multiple commimication modes; for example, individuals 
contacted directly can respond immediately, while others can respond later in accor- 
dance with instructions delivered to them — e.g., via a web site or by calling a toll-free 
number. 

The invention disclosed in the '170 application supports messages having em- 
bedded questions that call for response by the recipient. Such responses, when re- 
ceived, may be communicated to the message sender and/or accumulated. 

Also facilitated by the invention disclosed in the '170 is scheduling of message 
delivery, on a mode-by-mode basis where appropriate. Scheduling may include deliv- 
ery at a particular time or within a designated time window, or may involve preventing 
delivery during specified "black-out" periods. In some embodiments, scheduling may 
be automatic and based on considerations such as the recipient's time zone and the 
form of communication (e.g., to avoid awakening the recipient by telephone). 

However, the '170 application contemplates a system in which customers' cli- 
ent computers communicate via the World Wide Web (the "web") with a server im- 
plementing the foregoing functions. In other words, the interaction is essentially man- 
ual and stepwise in nature, with customers selecting options and indicating preferences 
in an interactive session. This model is generally unsuited to business applications re- 
quiring more automated, high-volume access to messaging functions. 

DESCRIPTION OF THE INVENTION 
Brief Summary of the Invention 

The present invention provides an application program interface (API) facili- 
tating interaction, generally (although not necessarily) via the Internet, with a message- 
handling facility such as that disclosed in the '170 application. In accordance with the 
invention, application programmers utilize a markup language (preferably XML- 
derived) to configure applications for compatibility and communication with the mes- 
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sage-handling facility. The API is capable of processing high-volume requests for 
message routing, status information, and various other functions on an automated basis, 
enabling businesses to make routine use of these functions. 

Indeed, the range of business-to-business and business-to-consumer organiza- 
5 tions that can benefit fi^om flexible messaging services is virtually limitless. For exam- 
ple, an ciirline may obtain contact information from passengers v^en tickets are pur- 
chased. Should a flight be delayed or cancelled, the airline can generate a single notifi- 
cation for transmission to all passengers via the messaging facility; as the flight time 
approaches, efforts to reach passengers not yet contacted can be intensified according 
to defined escalation rules. Similarly, a club or other organization can send out notices 
of meetings, receive confirmations and preferences fi-om members, and alert them to 
changes using the messaging facility by means of the API. The message need be writ- 
ten and transmitted by the organization only once; all remaining operations, from bulk 
re-transmission to collecting and organizing responses, are performed automatically. 

In accordance with the invention, a message server comprising a plurality of 
modalities for transmitting messages is associated with an API. An application, typi- 
cally implemented on a remote server, is configxired to receive a message and a desig- 
nation of one or more transmission modalities, and is further adapted for interaction 
with the API. The API comprises stored instructions supporting the interaction. Upon 
receiving the message and the designation fi"om the application server, the API causes 
the message server to transmit the message according to the designation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing discussion will be xmderstood more readily from the following 
detailed description of the invention, when taken in conjunction with the accompanying 
drawings, in which: 

FIG. 1 schematically represents the environment of the invention; and 
FIG. 2 schematically illustrates the components of the API and its mode of in- 
teraction. 
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DETAILED DESCRIPTION PREFERRED EMBODIMENTS 

1 . Technical Context 

The functions of the messaging system are implemented by a server 125, which 
may be realized as a single workstation or as a network of server computers, depending 
on the activity level and included functionality. For explanatory purposes, server 125 is 
represented as a single machine that includes a network interface 127 continuously 
connected to the Internet. Network interface 127 and the other internal components of 
server 125 intercommunicate over a main bidirectional bus 130 (which may be a physi- 
cal bus in a single hardware device, or can instead represent a network such as a LAN 
or a WAN). The main sequence of instructions effectuating the functions of server 125 
and facilitating interaction among customers, server 125, the Internet, and other modes 
of communication reside on a mass storage device (such as a hard disk or optical stor- 
age unit) 132 as well as in a main system memory 134 during operation. Execution of 
these instructions and effectuation of the functions of server 125 is accomplished by a 
central-processing unit ("CPU") 136. 

A group of functional modules that control the operation of CPU 136 and per- 
form the operations of server 125 is shown conceptually as located in system memory 
134; once again, however, it should be stressed that this organization is for explanatory 
purposes. The various modules and servers may indeed be implemented as active proc- 
esses ruiming on a single machine, but functionality may instead be distributed among 
multiple machines (or processors within a single machine), once again depending on 
the activity level and included capabilities. 

An operating system 140 directs the execution of low-level, basic system func- 
tions such as memory allocation, file management, and operation of mass storage de- 
vices 132. At a higher level, a control block 142, implemented as a series of stored in- 
structions, manages interaction among the various functional components of the server 
and ensures proper routing of data thereamong. 

Although server 125 may be capable of communicating directly with customers 
by means of the web and electronic mail, as explained in the '170 application, the pres- 
ent application is concerned primarily with hardware-to-hardware communications. 
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Accordingly, an API 145 receives and processes communications from external 
sources, and transmits proper responses to those sources, via network interface 127. 
API 145 represents a programmatic interface for direct connection to appropriately con- 
figured third-party applications. The pattern of intemction with the external source, 
including the content of transmissions thereto, is handled by a transaction server 1 50. 
Transaction server 1 50 has access to various databases, collectively indicated at 1 52; 
these databases, discussed in greater detail below, are ordinarily stored on devices 132 
and accessed as necessary. Depending on the requests received by API 145, transaction 
server 1 50 causes messages to be assembled and transmitted to designated contacts, and 
retrieves and assembles information for transmission to outside inquiries. Credit-card 
validation and billing for services are handled by a billing server 160. 

The various functions performed by server 125, which result in different pat- 
terns of interaction with customers, will now be described. 

1.1 Media Conversion and Basic Message Transmission 

A series of media servers, collectively indicated at 175, represent the interface 
servers that format messages for transmission; these messages may be in the form of 
voice, text (for transmission by e-mail, web or postal mail), or other desired format. 
Messages and media designations are received from remote applications via API 145, 
and once transaction server 1 50 has received sufficient commands and content to fully 
specify a message (i.e., the inessage body, the recipient(s), desired delivery methods, 
and message options such as delivery scheduling and/or escalation rules), a message 
"job" is created and stored in a database 152. The job is passed to a job queue server 
165, which is responsible for implementing and scheduling all message jobs. 

At this point, the message remains in the format in which it was generated. As 
noted previously, however, server 125 is capable of receiving messages, via the inter- 
face servers, in one format and transmitting them in a different, customer-selected for- 
mat. The functions of media conversion and message assembly are performed by a se- 
ries of message delivery servers, collectively illustrated at 167, dedicated thereto. The 
appropriate message delivery server 167 converts messages to the specified format and 
causes their transmission, via the designated communication medium, by means of a 
corresponding device driver selected from among a suite of drivers. The drivers oper- 
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ate a series of transmission devices, which include network interface 127 for e-mail 
and/or web-based message delivery; a telephone interface 1 70 for message transmission 
by telephone, facsimile, pager, or handheld wireless device (although it should be noted 
that pager and wireless transmission can occur through network interface 1 27); and a 
document-generation module 172 for message transmission by postal mail or overnight 
courier. 

The timing of message transmission is governed by job queue server 165. In re- 
sponse to the customer's authorization to send a message, job queue server 165 triggers 
the conversion and transmission operations just discussed. Job queue server 165 also 
contains (or, as shown for illustrative purposes, communicates with) a scheduling mod- 
ule 1 80, which can orchestrate transmission of messages at customer-specified times 
based on the computer's internal clock. 

Server block 1 65 may contain a text-to-speech conversion module, enabling 
customer-provided text to be transmitted by voice to the recipient by means of tele- 
phone interface 170. Conversely, telephony server 175 may be configured to respond 
to spoken customer commands, allowing the customer to compose and address a mes- 
sage by telephone (i.e., by communicating with server 125 by means of telephone inter- 
face 170). 

In still more complex operational modes, server 125 may facilitate catenation of 
message — either as separate segments of the same format, or as segments encoded in 
different formats. In the case of audio messages, for example, a message delivery 
server 167 may append an audio "header" (typically a so-called "professional prompt") 
and a "trailer" to the customer's message. Thus, when the recipient answers the tele- 
phone, the header portion of the message may tell him that he is about to receive a mes- 
sage fi^om the customer, and the trailer portion may facilitate response (as explained in 
further detail below). 

L2 Confirming Message Receipt 

Any of a variety of techniques can be used to assess whether and when a mes- 
sage is received. Many e-mail systems natively support receipt confirmation. Alterna- 
tively, a URL can be embedded in the message; when the recipient receives the e-mail 
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and clicks on this URL, receipt is automatically recorded. Moreover, the URL- 
specified web page may contain questions inviting response by the recipient, who 
thereupon transmits the web page back to server 125. 

Hard-copy deliveries can be tracked through the courier or by means of a fol- 
5 low-up telephone call to the recipient, while for telephone messages, the recipient can 
be asked to press a number to confirm receipt. In the context of telephone messages, it 
may be useful to detect whether a person or an answering machine has answered the 
phone. This determination can be used, for example, to select a proper audio header or 
even to choose between alternative messages, which may differ depending whether the 
message is delivered to the recipient or a recording device; an answering machine, ob- 
viously, would not be asked to press a number to confirm receipt, nor would delivery 
typically be confirmed to the sender if the message was left on an answering machine. 
To implement answer detection, telephony server 147 is programmed to monitor the 
level of noise on the line once a connection is established, distinguishing between a 
"silence" noise level and a "speech" level. If an individual answers, he or she will typi- 
cally issue a short greeting; that is, the signal pattern of a human answer is a short 
speech signal followed by silence. An answering machine, by contrast, will generally 
issue a long greeting ("Hello, you have reached the Smiths Based on the ob- 
served lengths of a sustained speech signal and an ensuing silence, telephony server 
147 forms an initial guess as to whether a person or a machine has answered. If a per- 
son is guessed, telephony server 147 will play the audio header that prompts the an- 
swerer to press a touch-tone key, and if the proper touch-tone pulse is not detected, 
server 147 may revise its guess and assume that it is commimicating with an answering 
machine. 

13 Message Scheduling 

It may not be appropriate to transmit messages by certain modes during par- 
ticular time periods at the recipient's location. These "blackout" time periods may be 
established automatically by server 125, or may be designated by the customer or the 
recipient. Via API 145, an external application may indicate blackout time periods for 
a particular message, or may permanently designate such periods for particular contacts 
(and particular communication modalities). Most commonly, permanently designated 
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blackout periods are used to prevent messages from being sent by telephone or pager 
during times when the recipient is generally likely to be asleep or away from the com- 
munication modality. Message-specific blackout periods may be utilized by message 
senders familiar with the recipient's immediate schedule, or who do not wish to perma- 
nently establish blackout periods. 

Conversely, the external source may specify particular allowed time windows 
within which a message must be delivered. Once again, these may be established per- 
manently for particular contacts or "on the fly" for specific messages. 

Time-zone scheduling may be employed automatically. For example, if the 
customer authorizes immediate message delivery at a time that would be late at night 
where the recipient is located, or schedules message delivery for such a time, transac- 
tion server 150 may cause the customer to be prompted with this information and asked 
to confirm or reschedule delivery. 

1.4 Escalation 

Rather than send a message to a prospective recipient redundantly via multiple 
communication modalities, transaction server 150 may be configured to allow the 
specification of escalation rules for sequential transmission as necessary. The external 
application selects a plurality of commimication modalities and/or contacts, and criteria 
in the form of rules governing their use. Typically, an escalation rule will specify re- 
sort to a different communication modality (or a different recipient) if delivery of the 
message is not confirmed by a specified time, or within a specified period, using the 
current connmunication modality. 

Like scheduling restrictions, escalation rules may be defined permanently for a 
contact (and stored, along with "address book" information pertaining to that contact, in 
database 152b) or may instead be defined for a particular message. Default message 
modalities and permanent escalation rules are particularly useful in the context of dis- 
tribution lists, since the external application can simply enter a message and leave it to 
server 125 to deliver it to every person on a selected distribution list in accordance with 
each contact's escalation rules. On the other hand, message-specific escalation rules 
may be designated for particular messages transmitted to API 145. 
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To implement the escalation rules, the time period specified in a rule relevant to 
the initial message transmission is sent to scheduler 180. At the end of that time period 
following transmission, transaction server 1 50 detemiines whether the message has 
been received in the manner described above. If not, the escalation rule (defined in 
database 152b or in the transaction record for the particular message) is executed, and 
the message re-transmitted by a different modality. If further escalation rules remain 
for the message, the appropriate time period is once again provided to scheduler 1 80, 
and the flow sequence repeated. 

2. An Exemplary Application Program Interface 

With reference to FIGS. 1 and 2, external sources such as a server 190 generate 
requests for messaging functions and status information, and transmit these to server 
125 via a computer network, such as the Internet, for processing. FIG. 2 illustrates in 
greater detail the role and basic components of API 145. Requests are actually gener- 
ated by an application 210 running as an active process on server 190. Application 2 1 0 
formats these requests in the syntax allowed by API 145. Requests received by API 
145 from application 210 are analyzed by a parser 210, which interprets the request and 
causes the various server modules of server 125 to take appropriate action. The server 
modules may generate direct responses to the requests or provide status information for 
transmission to application 210. A converter 220 places such information into state- 
ments conforming to the API syntax prior to transmission. 

Preferably, the API syntax conforms to the conventions of XML, using '^ags" to 
characterize elements such as statements and field data. A tag surrounds the relevant 
element(s), beginning with a string of the form <tagname> and ending with 
</tagname>. Thus, parser 215 can be (or be based on) a conventional XML parser. 

The contents of a communication to or from API 145 take the form of a "docu- 
ment," which contains an identifymg tag and either a "Request" (for documents gener- 
ated by application 210) or a "Response" (for documents that API 145 returns to appli- 
cations 210). Document elements are hierarchically organized into objects. Each ob- 
ject specifies the contents of fields associated with the object, and may also contain one 
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or more nested, hierarchically inferior objects; this structure maintains the organization 
. of information, facilitates movement of information in meaningful packages, and al- 
lows for re-use of information without explicit repetition. 

At the highest hierarchical level, "Super Objects" define the communication as 
5 a Request or a Response, and contain one or more "Major Objects." The Major Objects 
specify key functional elements of messaging activities, defining the relevant user ac- 
coxmts and the nature of the desired message functions, and may contain sub-objects 
and/or entries for various fields within the Major Objects. Fields contain information, 
such as character strings or numbers, relevant to the objects containing them. 

10 The overall organization of a preferred implementation of API 145 appears in 

summary form below; following the summary, the various objects and fields are de- 
scribed in greater detail. It should be understood that this API is illustrative only. 

Table 1 

13 Basic API Organization 

L Super Objects: contain required fields and one or more major objects 

A. Request (fields:) 

i) UserName 

20 ii) Password 

iii) Domain 

iv) OEMId 

v) OEMPassword 

vi) RequestType 



25 



B. Response: same fields/objects as request + errors, warnings 



II. Major Objects: required elements of docimients, may contain sub- 
objects and fields 



30 
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Member (fields:) 

i) Command 

ii) Id 

iii) FirstName 

iv) LastName 

v) Company 

vi) UserName 

vii) Password 

viii) AllowNotices 

ix) Diaiinid 

x) Dial in Password 



Member (subobjects:) 

i) Contact Method 

ii) Billing (fields: Id; Billing Plan; CurrentBalance) 

iii) Credit Card (fields you'd expect) 

Contact (subobjects:) 

i) Contact Method (fields:) 



a. 


Id 


b. 


Transport 


c. 


Qualifier 


d. 


Ordinal 


e. 


PhoneNum, FaxNum, PagerNum 


f. 


Access Code 


g- 


Email Address 


h. 


Street 1 


i. 


Street! 


j- 


Suite 


k. 


City 


1. 


State 


m. 


Zip 


n. 


Country 


Contact MethodRef (fields:) 


a. 


Id 


b. 


FirstName, LastName, Company 


c. 


Transport, Qualifier, Ordinal 


d. 


AUowMultipie 
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Contact (fields:) 

i) Command 

ii) Id 

iii) Prefix (optional) 

iv) First Name, Middle Name, Last Name 

v) Company (optional) 

vi) Title (optional) 



C. Distribution List (fields:) 

i. Command (create, replace, append, delete, remove) 

ii. Name 

iii. Description 

iv. Id 



D. Job (fields:) 

i. Id 

ii. Charges 



Job (subobjects:) 

i. Message (fields:) 

A. Subject 

B. Template (optional) 

C. Id 

D. Date 



Message (subobjects:) 

A. MessageArg Objects: series of NameAi^alue tags: 



1) 


SENDER 


2) 


BODY 


3) 


ASK YESNO QUESTION 


4) 


QUESTION TO ASK 


5) 


EMAIL ADDR 



DeliveryTime Objects 
Delivery TimeModifier Objects 
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ii. Contact (to specify one-time recipient of message) 

iii. Delivery Request (elements:) 



A. DeliveryOptions field (in) 

B. Contact MethodRef sub-object 



Delivery Request (returned elements:) 

A. ContactMethod 

B. Contact 

C. Delivery (fields:) 



1) Id 

2) Timestamp 

3) Duration 

4) Status (Not Sent, Sent, Failed, Cancelled, Cancel 
Pending) 

5) Details (Bad Address, Delivery Address is unreach- 
able,No Ansv^rer, Busy, Answering Machine (assximed). 
Answering Machine, Maximum Delivery Attempts Ex- 
ceeded, Acknowledged, Modem, Hangup, Callback 
Later, Internal Error 

6) Size 

7) Cost 



DeliveryRequest fields (out) 

1) Id 

2) EstDuration 

3) EstSize 

4) Status 

5) Details 

6) Completed 



Range (fields:) 

i. Object (i.e., type of object trying to look up) 

ii. Type 

iii. Start 

iv. End 



wo 01/69385 



PCT/USOl/07727 



15 

Every transmission to API 145 requires a Request, which will generate a Re- 
sponse from API 145 (and the server modules with which it functions). The Request 
must identify one or more valid "members" by means of UserNames. A request con- 
tains the following required fields: 

5 Table 2: Request Fields 









Allowed ;\^alue$f 


Example' ll^cj 'i^^^'^ = 

=tV."' 'ii* ?!i;if!'' ■"^^ir^ir' vT^'^" 










<Ui5CTNaJtne:=^^ m-:,^ ^ 




PasswWd fSi^JHt^ 






<PassWordi^i;123ffi^-.::^' j 


doifnaitf^ii^^ 


P^yi §$&rgiariizatj6 






<E>oifilin>PGEtS^6m 




Ihe: domain^ LE]K(identifies t6ffipanyi6r::i^ 












In 




<OEI^ass\vdrd>r^ 




.'V^-Ti sv^r ^^"^li^^^ry/m^^^ yY^M^^y-ft^^. i-z'^'-^:^5>'^^^ 
gloes hdt;mke :^y^d 




^lidatfei:' 


5Reqii^tT)pe^vaifi3aW-: 



(In this and other tables, the In/Out column indicates whether the field is used in 
a Request (in), in a corresponding Response (out), or in both.) 

10 In addition to fields, the Request will generally contain one or more Major Ob- 

jects, Typical actions include: send a message to specified recipients; add/edit/delete 
member, distribution list, contact information; look up the status of a job; send a billing 
inquiry. The following represents a typical Request (with the Contact Object, discussed 
in greater detail below, indicated but not actually specified): 



15 
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<Request><UserName>Ralph W<AJserName> 
<Password>abc 1 23</Password> 
<Domain>POETS</Domain> 
<OEMId>OEMId</OEMId> 
5 <OEMPassword>OEMPassword</OEMPassword> 
<RequestType>validate</RequestType> 
[Contact Object] 
</Request> 

The Response is generally returned with the same objects that were included in 
the Request; if> however, the Request asks for information (e.g., a request for message 
status or for billing information), some objects or fields may be added or changed. In 
addition, the Response will contain Errors and Warnings fields as appropriate: 

















Set-t^thje^humber pfie^^ 

w^^hippr^^sin^^ti^^ 

object^indl^^iifth^ife 


6ilt';ii;- 








Set^t^tl^e ihujpfegr pf^gmii 

prpficwrsmg the^majorj^ 
cludea^uiime;Request^-pf?- --P;Jv, 






^Waraings>&^^^ 



Table 3: Errors and Warnings (Response Fields) 

Errors and Warnings are described in greater detail below. 

The following represents a typical Response (with the Contact Object once 
again indicated but not actually specified): 

<Response> 
<UserName>RalphW<;/U serName> 
<Password>abc 1 23</Password> 
<Domain>Poets, Inc.</Domain> 
<OEMId> OEMId<;/OEMId> 

<OEMPassword> OEMPassword</OEMPassword> 
<ResponseType> vol idate</ResponseType> 
<Errors>2</Errors> 
<Wamings>0<Warnings> 
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[Contact Object ] 
</Response> 



Requests and Responses specify one or more Major Objects as follows: 



Major Object 


Description 


Member 


User-level login that identifies a user account (end user or member) 


Contact 


Person or organization to which a message may be sent 


Distribution List 


A group of contact methods (for example, phone number, pager number, email 
address) to which a message may be sent 


Job 


Message to one or more contacts using one or more contact methods 


Ranae 


Used to look up other objects based on specific search criteria; for example, to 
look up a job by Id, or jobs sent on a certain date, or all contacts from the same 
organization 



Table 4: Major Objects 

Each Major Object contains zero or more fields and sub-objects, which may 
themselves contain additional sub-objects and/or fields. The various Major Objects 
will now be described in detail. 

Major Objects — ^Member : generally an end user of the messaging service. 

Major Objects — ^Member : — ^Fields: The Member object has the following fields: 













SbmmMdt"£l2 


RequestsrMc:^ 

actibns^-^'^&^'!'-^=^^--v^-'^.'-v'^"^-^^ 
Updiitc(JV4c^ify^ 




remoyei^l 




'■ 


¥md\r^:ddStiitifie£^ 
Responsettgja 


@j^date(in)j 


menc5^-,i;-^v 
stniS|:^;&^ 




FLrefl^affii^jJJ^^ 
^R^uu^jp^l' 


iiielmi^mbiiiSi^ 




Stnng^witiit 
ci^racter^ 

iim|^.|;ps 


<liiStNamS>ViiShi3J^ 


[ilastlJ^m^' T'iS 


llie; ineinbli^g:I4sKna^ 




StriSipvitti^ 
charaCt%M; 





5 



to 
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(Optional) • 


tjie mem^ef s cpmpahyVftiliatio 




String with 

character ; 
limit 




LJser>iame.p. J 


Th^menjJ^r's iogin; miist beig^ 
unique wM^ 


"4n': :■'*%■ 


String with 

a'32£-:; - 
climacter"^; 
lunitV . 


<Use^anij^yirginiaW|iiJsietJ^ 


Passvirofd 


Theinieinb;er's sra-et pfeVWordi i 


. .iv: ■■ -ry-z - 


Strihfe-with': 

^■^^ 

cnapcterj^l 
iiriiit:.':J ; 


Pass^rord>abcI23<^ 


/^lIo^Notices'j 


MgrksitlvisJir^ 
terested m 

odibirri ailmgs' speciticfoth is-dcH • ^ 




al^): -^i 
"FalM:'!f^^P 


<Ail!t>>vNotices>ti|u = ■ 'tJS;''';-' .O^r^^ 
</Ali6WNoHces>:rg 


Dailijrtld^};;:gr;; 

- - ^ - «™-*- ■ ' 


Tliijis^a.v^y fp^j^^ raeinber/|OL; ;.i 
identifj^'riM^ cSlihg^intp' J 
a^|tei^piDii§^ 




stringif ' 'v^; 


mamd>9i46^ 


DialinPassri;:-:: 


Sewsiaga; PIN^f; tfrey^ 




Nultoiq^ill 





Table 5: Member Major Object Fields 

Major Objects — Member — Sub-objects : In addition, the Member object con- 
tains the following required sub-objects: 

Major Objects — ^Member — Sub-objects — Contact Method: specifies communi- 
cation mode (e-mail, telephone, etc.) and contact information (e-mail address, tele- 
phone number, etc.) specific thereto. Contact Method sub-objects are fiirther described 
below in connection with the Contact Major Object. 

Major Objects — Member — Sub-objects — ^Billing: specifies the billing plan and 
details necessary to bill the member (such as a credit-card number). The object also 
describes the current account status. The following table sets for the required fields for 
the billing sub-object: 
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Description ^ ? 


Jii/Out 


Allowed 
Values, 


■ ' txairiple; ' 


14' 4 


Uniqueodentifjer : ■ . ; ^ 


Out;;;: 






Billing Plan -fi . : 


using .a-credit card% ^^^fe j^u^d^r: 




' ■ 
^■^^ 


gBimng|lari>kjyc33^^ - fei^t : 




Giiirentybalance in^U 
flpaiingliwint;!)^ 









Table 6 
Member Major Object 
Billing Sub-object 

The billing sub-object, in turn, contains a Credit Card sub-object, the fields for 
which are set forth in the following table; 





I^S(CiiptioiQ;^;E- 


In/6uth; 






P^tNpv^fc^lf 






stringtwith;- 

liinig^^:^ 






• „ lr*' • 


SA 


NumberasH;; 
c^diSc^M 


^MiteardNuy^e^^ il S 


Expii^tioiil 


nfohtK^aslitabrj 
pearsion -the:§^. . -.^ 




nuraberrasii^^ 
itiap^caxg: 






EKpii^dj^ep^ 
asiiF^feaisoffi^^ 
Uwa:edig^ar^ 




FpurgliQtni 




Street^ddres^o; 


l^tjl&flj^e^ 
stoeS^iddre^^^ 
foritnisjcardi"^;: 




Pjpfelinfepf; 
bilUg^^fS 

ttiisxfani^ife: 




Stree^ddress2? 


Sfcleoifdi lin^iof : / 
thfe-stj^gaa-;^:i.; 




of^illmyBi 
di(¥s;card^ 
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State ■ T v?^"'"' 


State of billing \ 
address for this 
card 




Use two- 
letter state i 
abbreyia- '\ 
tipn i • : 


<State>6A</State> --^'^'V ' ' -'-i^'" , 


Zip!; '■^^:/^r --*--^ 


Zip code . in the ;, 
U!5, poitiafctae 
outside,,.- 




Zip codes ■ 
can be^i- 

iiier^^i^Sir'' 
nirie digits; 
HyphMis:;;^; 
optional^' 










gguntr^; ;i 

pme.:^^-i:-r 





Table 7 
Member Major Object 

Billing Sub-object 
Credit Card Sub-object 

The following is an example of entire Member Object: 

<Member> 

<Command>create</Command> 
<FirstName>RaIph</FirstName> 
<LastName>Emerson</LastName> 
<Company>Poets R Us</Company> 
<UserName>RWE<AJserName> 
<Password>MyPassword</Password> 
<DialinId>12345</DialinId> 
<DialinPassword> 1 2345<yDialinPassword> 



<ContactMethod> 
<Transport>email</Transport> 
<Qualifier>none</Qualifier> 

<EmailAddress>ralph@Poets.com</EmailAddress> 
<j'ContactMethod> 

<ContactMethoc> 

<Transport>phone</Transport> 

<Qualifier>office</Qualifier> 

<Ordinal>0<Ordinal/Ordinal> 

<PhoneNum>617- 123-4567</PhoneNum> 
<yContactMethod> 

<BilIing> 

<BiIlingPlan>klck33kkkk<BillingPlan> 
<CurrentBalance> 1 .00<CurrentBaIance> 
<CreditCard> 

<FirstNaine>RaIph</FirstName> 
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<MiddleName>WaIdo</MiddIeName> 
<LastName>Efnerson</LastName> 
<CreditCardType>Master 
Card</CreditCardType> 
5 <CreditCardNumber>5 123 12341 234 1233</CreditCardNumber> 

<Expiration Year>200 1 </ExpirationYear> 
<ExpirationMonth>8</ExpirationMonth> 
<Street Address 1 > 1 3 1 3 Mockingbird 
Lane</Street Address I > 
10 <StreetAddress2>Poets R 

Us<yStreetAddress2> 

<City>Warren</City 
<State>MA</State> 
<Zip>01810</Zip> 
15 <CountTy>USA</Country 
</CreditCard> 
</Billing> 
</Member> 

Major Objects — Contact : identifies an individual to whom a message may be 
20 sent. A Contact Object contains one or more Contact Method sub-objects (described 
below), each of which identifies a way to reach the individual. Contact and Contact 
Method information may or may not be stored in a member's Address Book (i.e., the a 
collection of a member's Contacts and their associated Contact Methods stored in data- 
base 1 52b). Thus, a Contact Major Object may be created to be stored in an Address 
25 Book, or for one-time use. 

Major Objects — Contact — Fields : The Contact object has the following fields: 















CiSatcf(Add a^iiew Gbh^^^^ 

object ihf6ifSmi6h)-;f 
Remow (Remove^fefe^ 




updat^^-:;^"^j?ss;r;rfi 

refquiiEcd'only;;wben the ^ 
gpnt;acriStotbe:i|pd:^^^ 


i%omrriahd>^i^^Gdm ' i: 

gJJ^SJiirf^^ ^y}.iM^}Mkd\ 




©ommlriaJfiBl^ 
upMte;;6TiWmdyef.tHSS 


ijj^t^l-g 
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(Optional) 


Indicates the contact's _ 
prefenied title; for exam-"^ : 
pie, Mr;, Ms, Dr^ i^-^-. , . : 


In- 


String-- t:'-' ■ 


<ftefix>Miv</Prefi;^ ^ 


First^Narne v- 
Middle Name 
Last >fame ;^ 


TTie contact!s first, middle ! 

and l^^^t^h^'es;^fi^ 

last names are required # 

. - 1^. ^ vr j \ ■ *--:■> . 




Each name. nciQ IS a 
Strihg Wiffia 3;2^h^^ 
acteri!imiti: lv ^ v/ : : - 


<F:irstNamex>William. ..Vl \4 
</FirstNamei^ .l;^:' "■• V;-'- ^ 
"?^i4iddJeName>S;;^^^ 
</MiddleName> 1. - K 
<t^tName>Sn^espeare / :rf ■ ^ - yt; • .J 
</tastNam^^*>j=^:^':.!^>h::4i^;^.'^'^-'^ 


Eon^ahy ;:-L ^j- 
(PpUcma]> 


Indicates the- name of th 
cbmpafi/ orgM i^tionlg 
wiiiirwBich>the cbntactjs.:^ 
affiiiaffedr;?^^-^; 




Sfrii^iffiiSSrct^ 
abter^liniit^ivr: ^i^^:',^ ,;4;^.:^i>f^^ 


<^8mgan:^pe-li^^ 




Indicates Ef-jbb title: f&: the 

cbntaQtiv'^^^>%:.^t:lflf:.;# 




Sfring witfea :32i-clT^^ 
acterrlimifiii viS^L-?i^^S 


<T3tle>pirfettorM*S^;^^^ - "S-Si 



Table 8: Contact Major Object Fields 

Use of the Command field ensures that the Contact Object will be stored in the 
Address Book of the member with which it is associated. When the Contact Object is 
5 nested as a sub-object of a Job object (described below), the contact information will 
not be stored in an Address Book. 

The following represents a typical Contact Object (with Contact Method objects 
indicated but not actually specified): 

<Contact> 
10 Prefix>Mr.</Prefix> 

<FirstName>William</FirstName> 
<MiddleName>L.<VMiddleName> 
<LastN ame> Shakespeare</L astName> 
<Company>Globe Theater, Inc.</Company> 
15 TitIe>Director</Title> 
fContactMethod Objects] 
</Contact> 

Major Objects — Contact — Sub-objects — Contact Method : as explained above, 
20 • this object specifies the maimer in which a member may be contacted. A Contact 
Method sub-object may contain some or all of the following fields: 
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Field;:.,. 


Pescrlptibn . . 


Ih/Out • 

- 


A lip wedi Values , .: 


Example. r :-:: '.:'L iv. 




Identifies this 
Gpiitact Methp 
object^ V^ :-: ' ^ 


' ■ -"v. 
In oKOiit 


Required, based ;pn the logic 
for the parent Contact object. 
NibTE: TThe^or&Gf M^^ 
pbjecirdojps: not have; a €om- 
ra juid- fiejd; .ra is;nest.ed 
with m a ;Goritact2object:th^ 
does have?a Cpi^^^ 






Indicates deliVr: 
eiyJiTfeth(^r fl^i 




Einail;;-^iii^^J|:;^^ 


<rnbsjpipW '1 


(Required)!; J 


Indicat^^ifi^J^ 




v^IUeYfor?!^^^^ 


<Qailifiei?f6eHk;^ 




allpvys^en^ §1^ 

morp;&ri-^hej>^ 




Urisighei^intege^ 
gjni^liCgl^js^S^ 

cSn tptTitet^^ WJ'^ 

fiStghoiiein 

riaj[-;^ou Idibe, "0"^^ for the: seCrL: 
oifdpjSe Srclih'aPwo be "^iE^: 


^Mi^Bg^<g^^ T; 




iiumberfofei£gj 




distanjeifee^^ 

C!o^lalji;v^^^•'--U5^^^^i^^v^^':^v^;,^~^ "ilj?^ 






ftei-pa^eiiySiS? 




^^ed^Ij^wKj^ 

en te^ an-identi ly ing touchstone 
strjnggswnettm 






EraailSaddresSS 




iSSiiCalEemailSdditss 


dre|s:r;|.g[eMATA^ 






fiiiil 


StmjgfSvr^^ 


^StreetMlOO Earfc^e^^^?; 
tiue;^/Streieta^>%?-ig^;;i£;:']^^^^ 




5ee5n(iiiiii6bf# 




;>nngiwitb;3^hgra^ 


Ist^^t^^R^S^^ 
lit<?itreeti^^^;^ 










<Sui t^MiifS Stiite^^^:^i^ J^^: 
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City 


City r 


In 


Stn^ig with 32 charaicter liriiit 


<gty>]^w York<;^5^ . 




State f : 


In 


fwo-^frkracter-abbri^^^^^ 




Zip ^:%]:' ■ r 


Zip;cojli^in tl^e^^ 
US; postal code 
elsewhere; J:-*- 




Stringy -^^y- -^7 


?il^lO021?c/Z!i> -S; 




j^ouritiy : IS; J 




Sifring;:>yith 32 chiara^l^er limit ' 


<€)puntry>USA'</CpiW!ji^ • 



Table 9: Contact Method Sub-object Fields 

To denote a member's primary e-mail address, for example, the following syn- 
tax is employed: 

5 <Contact Method> 

<tran$port>eniail</transport> 

<qualirier>member</qualifier> 

<EmailAddress>ralph@poetsxom</Emai!Address> 

10 <yContact Method> 

The following example illustrates addition of a new contact to an Address 

Book: 

<Contact> 

<Command>create<7Coramand> 
15 <FirstName>AIbus</FirstName> 

<LastName>Dumbledore</LastNajne> 

<Company>Hogwarts School for Witchcraft and Wizardry</Company> 
<TitIe>Headmaster<n'itle> 



20 <ContactMethod> 

<Transport>phone<Transport> 
<Qualirier>ce!I</Qualifier> 
<PhoneNum>9785551234</PhoneNura> 
</ContactMetbod> 



<ContactMetbod> 

<Transpoit>pager</Transport> 
<PagerNum>888555 1 234</PagerNum> 
<AccessCode> 1030#<AccessCode> 
30 </ConUctMethod> 



</Contact> 
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Major Objects — Contact — Sub-objects — Contact MethodRef : once a Contact 
Method has been created and stored, it may be referred to using a pointer called a Con- 
tact MethodRef, The pointer contains the Contact Method's Id, or a combination of 
fields that will uniquely identify that Contact Method. 

5 A Contact MethodRef sub-object may contain some or all of the following 

fields: 



Fields:- 


Description : .\ : r|[n70ut )AH :r ; - 


Example /rl. ■ - ■ - ^^^^ 


I^;np;e|;..;^ 


Idehfi]B;es^his^£bn 
Methpjd oBject^ : 










pie„^;fl.eldsrai^CaJI^^^^ 
from\the7Gdnt^ ofc^^ 




KistingConfectfield^^^ 


<FijretNaine>Ron?/p 
Nam^;Weasley<c/E^tni^^ -'-J 
|>any>Hdgwaiis< ':, 


§ualifi6r-iK* - 


fem^ffiel^ 




fie j3s= "^'^ ^^[z ^^^^^ ' • ^ 


<Tran sfert>emai iS/Tra&sb^ 
<Qual ifi^r>ilome</Qua ^ -1 






' -- ; V : --.-jr : ^ ■ , , 


IgUus-field;& ^ti^^^ 

the^fii^JiohSct '% 
Qifgni;e%ts|i^5'6i^^^ 





Table 10: Contact MethodRef Sub-object Fields 

Major Objects — Distribution List : a Distribution List is a grouping of Contact 
10 Methods. It allows a member to send a message to all of the Contact Methods in that 
list A Distribution List object may contain some or all of the following fields: 
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Field 


Description 


In/Out 


Allowed Values 


Example 


Cominand 
(Required) 


Indicates the desired aclion. Options in- 
clude: 

Create (Create a Distribution List) 
Replace (Replace existing Contact Meth- 
ods in this list with the Contact Methods 
contained in this request) ^ 
Append (Add Contact Methods to the 
existing list) ^ ' \ 
Delete (Delete Contact Methods from the. 
iist)--;-;-;v->-7 .... 
Rempve,(Reniove the whole Distribirtion' 5 
List).;- : ■•v"-,;'.-: ' ■ •■ . - ^ 


In 


Must include one of 

the following values: 

create / . , 

replace 

append 

delete'"-*:.:;: 

remove : -: ]...■ 


<Coinmand>append 

</Comraand>.,:,; 


Name V 


Unique name f^^^ ■ 




When creating a list, 
giveit a imique name; 
forexample, - V 
''Gryffindor^l32- 
character lirriit): \ ; 
r^WTE:;W!i^nus^ 
any: other conimand': j 
option, you must enter 
cither Name or; Id 
field tpiSenti^; the 
Distribution List L - 


<Nanie>Gryffindpr</ ; 
Name> ~ - -- ^ • . -v^ 


Description 


Destnptive te^^^^ " ; T-: . 




Optional field : ;:f.:j; 


^escrip- ; -." :v .; 

tion>Giyffindor^ . ; -i 
Hbuse<VDescnf>tioh^^ 




Unique; identifier ifof^ 


- • ; • . 

In/Oxxt I 


If the value of the -; ; : 
Command field is ; ; :\ 
create, no Jd field is 
required;.;if amy other: ; 
value, enter a.yalue:,;;: 
or either Name-or-Id: ■ 





Table 11: Distribution List Major Object Fields 

In addition, the Distribution List object must have a list of Contact MethodRef 
sub-objects (i.e., pointers to already-created Contact Method objects). An exemplary 
5 Distribution List object is as follows: 

<Distribution List> 

<Command>append<yConimand 
<Name>GryfBndor</Name> 

<ContactMethodReC> 
10 <LastName>Potter</LastName> 
<Transport>email</Transport> 
</ContactMethodReC> 
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<ContactMethodRef> 
<Id>kkk3blkk</Id> 
</ContactMethodRef> 

</Distribution List> 



10 



Major Objects — ^Job : a Job object contains a message to one or more Contacts 
using one or more Contact Methods, and contains sub-objects that define the specifics 
of the messaging task (e.g., the sender, the body of the message, recipients, etc.) A Job 
object also contains at least one Message sub-object (described below), and one or 
more Delivery Request or Contact sub-objects. 

A Job object contains only two fields, and these are specified only in a Re- 
sponse: 













identifier SSi^^ . - 




<id>kfiabikk<^ Mm 






FiBxting.pomtB 





15 



Table 12: Job Major Object Fields 

Major Objects — ^Job — Sub-objects — Message; the Message sub-object speci- 
fies the actual message. It includes fields and optional MessageArg Objects, and al- 
lows the requester to specify delivery times. 







In/Out^ 














FiHd^ijp/sales me 
















©ntweJideWtifiefc^Gi'S 
this^Nfessage subrBiSst? 






"i-r; ''Jl^'t;!!''" ■J; wssfi", •■ ■■■■■■ .js 
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©ate- - ■. ' 


Marks the date and 1- ' 
time the nriessage was 
submitted : ■ 




^^i^- "^ - ■ . . ■ : 


<Date:^199?;U)i20:: V: : : 
19:14:39</paM^^:;^^^ 


L^ii very 1 line 


Marks the requested ; ;:; 
timie of delivery ; ' 






<Delive^Lv;-Vi's^'^C'^'V^ 
ry 1 inie>.i 9y9;-l<):2.0i:; ; 
1 9: 14 :39</De\W0X 




Opt ions related ti^the^ ; 
requested, deliver^tim 






<D.el iveiyiFimeModi^;^ ^ ' < 

fj?f>S%m^t^/D^ri^^^ 

TiMe^SafflS^ 



Table 13 
Job Major Object 
Message Sub-object Fields 

Major Objects — ^Job — Sub-objects — ^Message — MessageArg Sub-objects : a 
Message object contains one or more MessageArg sub-objects that consist of a series of 
NameA/^alue tags according to the following syntax: 



10 



<MessageArg> 

<Name>SENDER<Name> • 
<Value>Hermione Grainger</Value> 

</MessageArg> 



The optional MessageArg NameA^alue tags are as folio vv^s: 



— - jj ; ^t '^V v^t rp.r.; 



Exiaim§m 



Ghau^'cter 
strmg:' 



alKntethods^gf^^ 
p ortle x^epfcblnafly^ 



<V|lu^?0^ 



shouldl)efenciosediin^^ 



[iKimjsehekluled: ^ 
^esstoffiB^fbre^ 
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YES" V;-' 
NO " 


If aiyes/no question is; 
aiskedj- this should be 
set to. YES, otherwise ■ 
NO;: for example,,^ ^ 


<MessageArg>;j:/; . , ■ 

<Nabi&^SKlY£SN02QUEST^ i 
<Value>YFS</Vahie> =' 






iftfe^- 

ASK^YESNO^QUES; 
TlO^fieldyis^s^tt^ 

& ukjy- UOW' mid, UvlU Lw - 

^nter the- actual text of 

the?qfifestiori^/S 


<Messag(eArg>:^:r:' • .^'/r^*; -^v;:' . S 
<Name5^:<QUES¥l0Ni.TO ASK</Nainei>- 

^Vfc^aj^A 






The^gnml address tfjat" 
is in the>l^m;f^s 
M^Repiy^ 
whenjseridingj^ 
sag§^ enSil.:^;:/;; 


<<Mess^eArg>\v:-^ '■rW\'- 'Jy^yA" '^t^r."'^ 
^an^^E^lL^^DDItki^am 



Table 14 
Job Major Object 
Message Sub-object 
5 MessageArg Sub-object Tags 

An exemplary Job Object is as follows: 

<Job> 

<Message> 

<Subject>Extra Quidditch Practice</Subject> 
10 <TempIate>generic</Template> 

<MessageArg> 
<Name>SENDER</Nanie> 
<Value>01iver Wood<A^aIue> 
</MessageArg> 

15 <MessageArg> 

<Nanie>BODY</Name> 
<VaIue><![CDATA[ 

I have scheduled an extra Quidditch practice session before the match with Slytherin. Be 
there Wednesday at 8:00AM sharp. 
20 ]]> 

<A^alue> 
</MessageArg> 

<MessageArg> 
<Name>ASK_YESNO_QUESTION</Name> 
25 <VaIue>YES<yValue> 
</MessageArg> 

<MessageArg> 
<Name><QUESTION_TO_ASK</Naine> 
<Value><![CDATA[ 
30 Can you make the practice session ?]]> 
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<A^alue> 
</MessageArg> 

<MessageArg> 
<Name>EMAIL_ADDR</Name> 
5 <VaIue><![CDATA[ 

wood@Hogwarts.edu]]> 
</Value> 
</MessageArg> 

</Message> 
10 <Contact> 

<Fir5tName>Hany</FirstNanie> 
<LastName>Potter</LastName> 
<ContactMethod> 
<Transport>emaiI<;/Transport> 
1 5 <Emai lAddress>potter@hogwarts.edu</Emai I Adddress> 
</ContactMethod> 

</Contact> 

<DeI iveryRequest> 

<ContactMethodRef> 

20 <LastName>Weasley</LastName> 
<Transport>email</Transport> 

</ContactMcthodRef> 
</DeliveryRequest> 
</Job> 

25 Major Objects — ^Job — Sub-obiects — Delivery Request : the Delivery Request 

sub-object allows the requester to specify a recipient for a job, as well as to specify de- 
livery options (as fields within the sub-object). The Delivery Request Object may 
contain a Contact MethodRef sub-object (to refer to a previously created contact 
method for the recipient) or may instead refer to a Contact sub-object of a Job object 

30 (for one-time use of that Contact/Contact Method). 

An exemplary Delivery Request sub-object is as follows: 

<DeliveryRequesP' 

<ContactMethodRefi> 

<LastName>Potter<l.astName> 
35 <Transport>email</Transport> 
<Qualificr>home<VQualifier> 

<yContactMethodRef> 
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</DeIiveryRequesP' 

The Delivery Request sub-object is also returned by API 145 as a Response. 
Furthermore, when an existing Job object is retrieved using a Range object lookup (de- 
scribed below), that job's Delivery Requests are also returned. 



5 The Delivery Request sub-object may contain the following fields: 
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Table 15 
Job Major Object 
Delivery Request Sub-object Fields 

5 

An exemplary Delivery Request Response is as follows: 

<DeIivefyRequest> 

<lD>kztubkkkk</ID> 
<EstDuration>80</EstDuration> 
10 <Status>Not Sciit</Status> 

<DeIiveryOptions>Staiidard</DeliveryOptions> 

<Completed>false</Completed> 

<ContactMethod> 

<ID>kit5bkkuk<ID> 
1 5 <Transpoit>phone</Transport> 
<Qualifier>office</Qualifier> 
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<Unreachable>false<7Unreachab!e> 
<EnnailAddress>poner@hogwarts.edu</EmaiiAddress> 

</ConlactMethod> 

<Contact> 

5 <ID>kk36bldddc</ID> 

<PrefixXPrefix> 

<FirstName>HarTy</FirstName> 

<MiddleName><MiddleName> 

<LastName>Potter</LastNaine> 
10 <Coinpany>Hogwarts School for Witchcraft and Wizardry </Company> 

<Title>Student</Title> 

<OneTifne>tnie</OneTime> 

<yContact> 
</[)eIiveryRequest> 



Major Objects — ^Job — Sub-obiccts — Delivery Request — Delivery Sub-object : 
the Delivery sub-object never appears in a Request. It is returned by API 145 as a sub- 
object of a Delivery Request object when a Range object lookup (see below) is per- 
formed on a job. 

20 The Delivery sub-object may contain the following fields: 







S^. - Tit.. 


i-:"^i?^^<ni;-rr" 














yi^^tampr 








g4-i5^<iTiiiS^^ ■ -^-^'^^1 






Is* 

; ^^^^ ^ 


i tit ^^^i^V"^ 






SEent (This* Deliver h"asl8eenlsucce^ 

Tailed ifThefmairattefhptf^^ 
Cancellcd^^V^ouTt^DbliveW^ 


3'.r-l ' - ■'''^ 


(|^|^ 





wo 01/69385 



PCT/USOl/07727 



34 





Gives the-following. information about the 
sfatus of tbis^dd 












Bafd.Addrj^s= -.■ -^-^ff'^^^^- ■'''■■'^^^^^0>^-' ] ''. 
Delivery Addresis is u'nrjeachable 1^6 hir* 
Iher attempts will beirifiddfe^^^^ VLU 
No Answer (anothe'fedelivery. may :S§at^^ J. - 


-r. .• , -. 


■ ■ .''.-■...•li.'.^.... 






" V "^^^ 


Busy (anothfer deliVi^ryma^^ 
Answering Machine:^^^ 


p||;i: 










sage^deliyer^ j no Mttfer ^^^^ V 

mkde)::iSife^S:K-:!^,^iJii^^ 
ApSyl^ld'gM^^^^^^ 


••:=;&-^-'--" 






• " ■ ''}ip'7:^:'y y' 'i''yW? 




Maximtin^Qieliv^ 






<Cetaii|>Mp^^ 






(NSfurthe^^^ vwJI^B^i'marfe^^ ^^^.'^ 
gtefjieSoJ^^ 

M o4cjm[(§5vfurth wil tbfe^ade;); 
Hangu p. (gall.w^ 
cbuld^lSiSeHyS-SdSm 






- T ■ r : ■ " ' T^Tvr ■ J - ■ ' 






CalIback|lJ^^^ 












later c£dlgack^ anotheSci|iiyer^ ^\ 

t^iteriiali^Brr^^ 
nSay SttSngtanpt^e^^^^ 
















*. :^L^•■;';TV:v^?-■ ; 








5runibei|&£i)a^ 


0B^.X : 


StandaM 

urgeiitS5S:--if:i 


;: . • • - r,.. - 




Cost.-LTt^.-. 


A:ctual"c5st':for,this;^^^^ 























Table 16 
Job Major Object 
Delivery Request Sub-object 
5 Delivery Sub-object Fields 

Major Objects — Range : The Range object facilitates retrieval of a list of ob- 
jects based on specified criteria. In particular, the Range object can retrieve Distribu- 
tion List, Job, and Contact objects. The Response to a Range object returns the re- 
10 quested objects. 

The Range Major Object may contain the following fields: 
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Fields Description :|=]n/Out : Allowed Values 


Example 


Object 
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Table 17 
Range Major Object Fields 



5 The Range object is always included in a Request object, with the value of the 

RequestType set to "lookup." The most common use for the Range object is to look up 
a Job object by Id, for example, 

<Range> 

<Object>job</Object> 
10 <Type>Id<yType> 
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<Start>kkky5btk</Start> 

<Range> 

Error Handling : Errors fall into three classes: parsing errors, fatal errors, and 
errors/warnings encountered while validating any object or field. 

Parsing errors occur when the input XML tags do not conform to XML specifi- 
cations. Typical examples of malformed XML code include tags that are not closed 
and illegal characters; to avoid the latter type of error, fi^e-form text should be en- 
closed within CD ATA tags. When parsing errors are encountered, API 145 returns a 
ParseErrors object, which contains one or more sub-objects called ParseError and hav- 
ing the following fields: 
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Table 18 
ParseError Sub-object Fields 

An example is as follows: 
<ParseEnors> 

<ParseError> 

<ErrorString>Expecting *a name', found *?' yErrorString> 
<LineNumber>9</LineNumber> 
<ParseEnror> 
</ParseEn-ors> 
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A fatal error signifies a significant problem encountered in the course of proc- 
essing a Request. API 145 retimis a FatalError object with a single field (ErrorString), 
which indicates the nature of the error. For example, 

<FatalError> 

<ErrorString>User Transaction Server Unavailable,</ErrorString> 
<yFatalEn'or> 



Validation errors and warnings are attached to problematic objects or fields as 
"attributes." The Errors and Warnings fields of a Response object contain the follow- 
ing information: 
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Table 19 
Response Super Object 
Errors and Warnings Fields 

For example, if a Request contains an invalid telephone number, a warning at- 
tribute will be attached to the problematic <PhoneNum> field. If a Request fails to 
provide a Billing sub-object when trying to add a Member, an error attribute will be 
attached to the Member object. 

It will therefore be seen that the foregoing represents a fiiU-featured messaging 
system capable of operating in multiple communication modes and interacting with re- 
mote applications through a common, extensible interface. The terms and expressions 
employed herein are used as terms of description and not of limitation, and there is no 
intention, in the use of such terms and expressions, of excluding any equivalents of the 
features shown and described or portions thereof, but it is recognized that various modi 
fications are possible within the scope of the invention claimed. 

What is claimed is: 
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CLAIMS 

1 . A messaging system comprising: 

a. a message server comprising a plurality of modalities for transmitting 
messages, the message server being responsive to a remote application config- 
ured to generate a message and a designation of at least one of the transmission 
modalities, the message server communicating with the application via a com- 
puter network; and 

b. an application program interface (API) comprising stored instructions 
executing on the message server, the API receiving the message and designation 
from the application and causing the message server to effect transmission of 
the message according to the designation. 

2. The system of claim 1 wherein the API is configured to interpret XML 
syntax, the message and the designation being expressed as a request formatted in XML 
syntax. 

3. The system of claim 1 wherein the message server comprises a database 
for storing contact data, the API being configured to process a request from the appli- 
cation to establish a database record specifying a member and contact data for the 
member, the contact data including at least one contact method specifying a transmis- 
sion modality and data facilitating contact of the member via the specified transmission 
modality, the API causing the message server to send the message in accordance with 
the contact data. 

4. The system of claim 1 wherein the message server comprises a database 
for storing contact data for a plurality of members, the API being configured to process 
a request from the application to (i) access an existing database record specifying a 
member and contact data for the member, the contact data including at least one contact 
method specifying a transmission modality and data facilitating contact of the member 
via the specified transmission modality, or (ii) obtain contact data from the application 
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7 for a non-member, the API causing the message server to send the message in accor- 
dance with the contact data. 

5. The system of claim 4 wherein the API is further configured to process a 
request from the application to create a distribution list comprising a plurality of the 
existing database records, the API causing the message server to send the message to 
the members in the distribution list in accordance with the contact data. 

6. The system of claim 4 wherein the existing database record comprises a 
plurality of contact methods, the API being further configured to process a request firom 
the application specifying at least one of the contact methods, the API causing the mes- 
sage server to send the message to the member in accordance with the at least one 
specified contact method. 

7. The system of claim 1 wherein the API is further configured to respond 
to status requests from the application, the API returning, in response to a status request 
specifying a messaging task, status information pertinent to the messaging task. 

8. The system of claim 7 wherein the status information includes a status 
designation for the message, the status designation specifying (i) whether the message 
has been sent, (ii) whether the message was successfully received, (iii) whether the 
message failed, and (iv) whether the message has been cancelled. 

9. The system of claim 8 wherein, for each failed message, the API returns 
an explanation for the failure. 

10. The system of claim 1 wherein the message is addressed to at least one 
contact, the message comprising a question, the API causing the message server to pose 
the question to the at least one contact. 

1 1 . The system of claim 1 0 wherein the API is further configured to respond 
to status requests from the application, the API returning, in response to a status request 
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specifying the message, status information pertinent to the message including any re- 
sponse to the question by the at least one contact. 

12. The system of claim 1 wherein the API is configured to handle informa- 
tion in the form of objects, the objects including (i) member objects designating mem- 
ber infomiation for a plurality of potential recipients of the message, (ii) contact objects 
specifying information facilitating communication with the potential recipients in ac- 
cordance with a plxirality of transmission modalities, (iii) job objects specifying mes- 
sages and characteristics thereof, and (iv) delivery objects specifying modes of message 
delivery, the application providing the message and the designation in object form. 

13. For use in conjunction with a message server comprising a plurality of 
modalities for transmitting messages and an interface for communicating with remote 
applications via a computer network, an application program interface (API) compris- 
ing stored instructions executing on the message server, the API being responsive to 
application-originated requests comprising a message and a designation of at least one 
of the transmission modalities, the API causing the message server to effect transmis- 
sion of the message according to the designation. 

14. The API of claim 1 3 wherein the executing instructions interpret XML 
syntax, the message and the designation being expressed as a request formatted in XML 
syntax. 

15. The API of claim 1 3 wherein the message server comprises a database 
for storing contact data, the API being configured to process a request from the appli- 
cation to establish a database record specifying a member and contact data for the 
member, the contact data including at least one contact method specifying a transmis- 
sion modality and data facilitating contact of the member via the specified transmission 
modality, the API causing the message server to send the message in accordance with 
the contact data. 
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16. The API of claim 13 wherein the message server comprises a database 
for storing contact data for a plurality of members, the API being configured to process 
a request from the application to access an existing database record specifying a mem- 
ber and contact data for the member, the contact data including at least one contact 
method specifying a transmission modality and data facilitating contact of the member 
via the specified transmission modality, the API causing the message server to send the 
message in accordance with the contact data. 

1 7. The API of claim 1 6 wherein the API is further configured to process a 
request from the application to create a distribution list comprising a plurality of the 
existing database records, the API causing the message server to send the message to 
the members in the distribution list in accordance with the contact data. 

18. The API of claim 16 wherein the existing database record comprises a 
plurality of contact methods, the API being further configured to process a request from 
the application specifying at least one of the contact methods, the API causing the mes- 
sage server to send the message to the member in accordance with the at least one 
specified contact method. 

19. The API of claim 13 wherein the executing constructions are configured 
to respond to status requests from the application, the API returning, in response to a 
status request specifying a messaging task, status information pertinent to the messag- 
ing task. 

20. The API of claim 1 9 wherein the status information includes a status 
designation for the message, the status designation specifying (i) whether the message 
has been sent, (ii) whether the message was successfully received, (iii) whether the 
message failed, and (iv) whether the message has been cancelled. 

21 . The API of claim 20 wherein, for each failed message, the API is con- 
figured to return an explanation for the failure. 



wo 01/69385 



PCT/USOl/07727 



42 

22. The API of claim 1 3 wherein the message is addressed to at least one 
contact, the message comprising a question, the API causing the message server to pose 
the question to the at least one contact. 

23. The API of claim 22 wherein the executing instructions are configured 
to respond to status requests from the application, the API returning, in response to a 
status request specifying the message, status information pertinent to the message in- 
cluding any response to the question by the at least one contact. 

24. The API of claim 13 wherein the executing instructions are configured 
to handle information in the form of objects, the objects including (i) member objects 
designating member information for a plurality of potential recipients of the message, 
(ii) contact objects specifying information facilitating communication with the potential 
recipients in accordance with a plurality of transmission modalities, (iii) job objects 
specifying messages and characteristics thereof, and (iv) delivery objects specifying 
modes of message delivery, the application providing the message and the designation 
in object form. 

25. A method of handling and transmitting messages to recipients, the 
method comprising the steps of: 

providing a message server comprising a plurality of modalities for transmitting 
messages, the message server being responsive to a remote application configured to 
generate a message and a designation of at least one of the transmission modalities; 

causing the message server to communicate with the application via a computer 
network; and 

c. providing an application program interface (API) comprising stored instruc- 
tions executing on the message server, the API receiving the message and designation 
firom the application and causing the message server to effect transmission of the mes- 
sage according to the designation. 
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26. The method of claim 25 wherein the API is configured to interpret XML 
syntax, the message and the designation being expressed as a request formatted in XML 
syntax, 

27. The method of claim 25 further comprising the step of providing a data- 
base for storing contact data, the server processing a request from the application to 
establish a database record specifying a member and contact data for the member, the 
contact data including at least one contact method specifying a transmission modality 
and data facilitating contact of the member via the specified transmission modality, the 
server sending the message in accordance with the contact data. 

28. The method of claim 25 further comprising the step of providing a data- 
base for storing contact data for a plurality of members, the server processing a request 
from the application to access an existing database record specifying a member and 
contact data for the member, the contact data including at least one contact method 
specifying a transmission modality and data facilitating contact of the member via the 
specified transmission modality, the server sending the message in accordance with the 
contact data. 

29. The method of claim 28 further comprising the steps of (i) processing a 
request from the application to create a distribution list comprising a plurality of the 
existing database records, and (ii) sending the message to the members in the distribu- 
tion list in accordance with the contact data. 

30. The method of claim 28 wherein the existing database record comprises 
a plurality of contact methods, the request from the application specifying at least one 
of the contact methods, the message server sending the message to the member in ac- 
cordance with the at least one specified contact method. 

3 1 . The method of claim 25 fiirther comprising the step of responding to 
status requests from the application, the server returning, in response to a status request 
specifying a messaging task, status information pertinent to the messaging task. 
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32. The method of claim 32 wherein the status information includes a status 
designation for the message, the status designation specifying (i) whether the message 
has been sent, (ii) whether the message was successfully received, (iii) whether the 
message failed, and (iv) whether the message has been cancelled. 

33. The method of claim 32 wherein, for each failed message, the server re- 
turns an explanation for the failure. 

34. The method of claim 25 wherein the message is addressed to at least one 
contact, the message comprising a question, the message server posing the question to 
the at least one contact. 

35. The method of claim 34 wherein server responds to status requests from 
the application, the server returning, in response to a status request specifying the mes- 
sage, status information pertinent to the message including any response to the question 
by the at least one contact. 

35. The method of claim 25 wherein the API is configured to handle infor- 
mation in the form of objects, the objects including (i) member objects designating 
member inforaiation for a plurality of potential recipients of the message, (ii) contact 
objects specifying information facilitating communication with the potential recipients 
in accordance with a plurality of transmission modalities, (iii) job objects specifying 
messages and characteristics thereof, and (iv) delivery objects specifying modes of 
message delivery, the application providing the message and the designation in object 
form. 
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